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(57) Abstract: An abstract interface model for device drivers in a set-top terminal, such as for use in a cable or satellite television 
subscriber network. In a layered software architecture, a device driver abstract interface model allows communication between a 
client (112, 212) and the device driver (154, 254) regardless of the operating system (OS) under which the device driver operates. In 
a first embodiment, the architecture includes a dedicated (OS-specific) device driver interface (132), and a proxy uses a first abstract 
interface (122) to convert interface service requests from a client (1 12) into OS-specific calls to the device driver (154). For a client 
that directly accesses a dedicated (OS-specific) device driver interface (132), a second abstract interface (152) is used to convert the 
interface service requests into OS-specific calls to the device driver (154). Direct access to the OS-specific device driver interface 
(132) is therefore maintained. 
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ABSTRACT DEVICE DRIVER MODEL FOR THE PORTABILITY OF 
DEVICE DRIVERS ACROSS DIFFERENT OPERATING SYSTEM 

PLATFORMS 



BACKGROUND OF THE INVENTION 

5 The present invention relates to the field of 

digital set-top software/firmware for use, e.g., in a 
cable or satellite television subscriber network. In 
particular, an abstract interface model is provided for 
device drivers in a set -top terminal. 
10 Th e recent advent of digital set -top terminals has 

spurred the growth of subscriber television networks, 
such as cable/satellite television networks. Such 
terminals can, support increased levels of programming 
services and a variety of software -based applications 
15 and functions, such as an electronic program guide, 

stock or weather banners, shop and bank at home 
services, games, and the like. Moreover, this trend is 
expected to continue with the convergence of telephone, 
television and computer networks, and the rise of in- 
2 0 home computer networks. 

Each terminal includes different hardware devices, 
for example, tuners, demodulators, MPEG-2 Decoders 
(e.g., audio, video, and data), video encoders, audio 
mixers, and so forth, which are controlled by 
25 respective drivers. 

Moreover, each terminal uses an operating system 
(OS) platform for controlling the functions of the 
terminal. The OS has a hierarchical structure wherein 
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functions are separated according to their level of 
abstraction. At the bottom of the structure, the least 
abstract level or layer is the hardware device level. 
The next higher level is the device driver level. At 
5 the top of the structure, the most abstract level is 

typically the client level. Additionally, each level 
manages a set of objects, which can be hardware or 
software objects, and defines operations that can be 
carried out on the objects. 

10 However, conventionally it is necessary for a 

device driver to be implemented separately for each 
operating system platform, e.g., for different set-top 
manufacturers, or different set- top models from the 
same manufacturer. Moreover; a single hardware 

15 platform may be required to support different OS 

platforms. It is even possible for different terminals 
in the same network to have different operating 
systems . . 

Generally, continual operating system changes in 
20 set- top terminals is a result of improvements, cost 

reductions, new components, and second source 
manufacturers. This is problematic since, even though 
each network generally uses a single OS platform, the 
terminal manufacturer must create different device 
2 5 drivers for the different operating systems in 

different networks. The device driver for the OS of 
one network cannot be easily migrated to another OS in 
another network. 

The need to develop and provide updated device 
30 driver software/firmware to the terminals leads to 

additional expense for the terminal manufacturer and 
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15 



network provider. 

Specifically, device drivers for a particular OS 
are tightly bundled to the OS, which means each driver 
contains OS-specific details throughout the driver's 
implementation, so a full development cycle is required 
to develop drivers for each OS platform. 

These problem are compounded by the continual 
upgrading and replacement of terminals in networks as 
technology advances . 

Accordingly, it would be desirable to provide a 
device driver abstract interface model that allows the 
development of a single set of device driver code, and 
device user code that will compile and execute under 
different set-top operating systems. The interface 
should allow a device driver to be implemented only 
once while being usable under several operating systems 
and set-top platforms. One such suitable platform is 
the DCT5000 series terminals, manufactured by General 
Instrument Corporation, the assignee hereof. 

The interface should allow two-way communication 
between the device driver and a client. 

The interface should ensure that the hardware 
device appears the same to the terminal's client (e.g., 
whatever application or other entity is communicating 
25 with the device) regardless of the OS under which the 

hardware device operates. Similarly, the client should 
appear the same to the actual device driver regardless 
of the operating system. 

The interface should allow the sharing of 
architecture and code across both OS platforms and 
hardware platforms . 



20 



30 
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The interface should be usable with operating 
systems that have, or do not have, a dedicated 
(operating system- specif ic) device driver interface. 
The interface should be implementable using 
5 object-oriented or procedure- oriented programming 

languages . 

The present invention provides a device driver 
abstract interface model having the above* and other 
advantages . 
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SUMMARY OF THE INVENTION 



The present invention relates to an abstract 
interface model for device drivers in a set-top 
terminal . 

5 The invention allows the development of driver 

core logic only once. The core still needs to be 
compiled separately for each OS platform. 

In a particular embodiment, a method is provided 
for allowing communication between a client and a 

10 device driver in a terminal, where the terminal has an 

associated specific operating system under which the 
device driver operates. The method includes the step 
of providing a first abstract interface for converting 
a service request from the client that has a format 

15 that is operating system- independent into a call to the 

device driver that has a format that is compatible with 
the specific operating system. 

In particular, the first abstract interface is 
adapted to provide the call to the device driver in any 

20 one of a plurality of different formats that are 

compatible with a corresponding plurality of different 
operating systems . 

When a dedicated (OS- specif ic) device driver 
interface is present, the device driver interface is 

25 adapted to receive a second call directly from another 

client that has a format that is compatible with the 
specific operating system. The second call does not 
pass through the first abstract interface. Moreover, 
the device driver interface provides the second call to 

30 the device driver via a second abstract interface. 
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A related method for allowing communication 
between a client and a device driver in a terminal, 
where the terminal has an associated specific operating 
system under which the device driver operates, includes 
5 the step of providing a first abstract interface for 

converting a message from the device driver that is in 
the format of the specific operating system to a 
corresponding message in an operating system- 
independent format for use by the client. 

10 The first abstract interface is adapted to convert 

the message from any one of a plurality of different 
formats that are compatible with a corresponding 
plurality of different operating systems into the 
operating system- independent format for use by the 

15 client . 

Corresponding apparatuses are also presented. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a device driver abstract 

interface model for use with an operating system that 

has a dedicated device driver interface in accordance 

5 with the present invention. 

FIG. 2 illustrates a device driver abstract 

« 

interface model for use with an operating system that 
does not have a dedicated device driver interface in 
accordance with the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

The present invention relates to an abstract 
interface model for device drivers in a set-top 
terminal . 

5 Known object-oriented design techniques provide a 

method for abstractly creating objects. Mainly, the 
designer can create an object that provides an abstract 
interface without directly knowing the details of the 
instantiation of the object. This occurs dynamically, 
10 at the run time of the software. 

The invention extends or modifies this idea as 
follows. Only a single driver interface is created for 
all operating systems. This is done at the time the 
source code is compiled, and only happens once 
15 (statically) . 

Accordingly, when a new OS platform is developed, 
at most, a proxy, an OS -specific driver, and the OS- 
specific driver support require development. This 
typically represents only about 10% or less of the 
20 driver development cycle, thereby resulting in 

significant cost and time savings. 

Specifically, all of the device driver logic is 
located or implemented in the device driver core 
control. This module or sub-system resides immediately 
25 above the hardware device level, and communicates with 

the hardware device either directly, or with the 
assistance of the OS-specific driver support sub- 
system. Note that the core control includes the 
majority of all the code in this architecture. 
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The device driver core control implements the 
logic defined in the device driver abstract interface. 
This interface defines what services the driver must 
provide. The core control includes all code required 
5 to provide those services . 

FIG. 1 illustrates a device driver abstract 
interface model for- use with an OS that has a dedicated 
device driver interface in accordance with the present 
invention. The dedicated device driver interface 130 
10 may be, e.g., Windows CE from Microsoft (tm) . 

A layered device driver model 100 includes a 
number of levels 110, 120, 130, 140, 150 and 160. 
Typically, the OS requires just a driver implemented to 
its interface, in one level. A bottom level 160, which 
15 is the least abstract level, includes the hardware 

device itself 162 in the set-top terminal. 

The next abstract level 150 includes a second 
device driver abstract interface 152, a device driver 
core control 154, and an OS-specific driver support 
20 156. The next abstract level 140 includes an OS- 

specific device driver implementation 142. The next 
abstract level 130 includes an OS device driver 
interface 132 . 

The next abstract level 12 0 includes the first 
25 device driver abstract interface 122, and a device 

driver proxy 124 . 

The next abstract level 110, which is the highest 
level, includes a client 112 that is using the device 
driver abstract interface 122, and a client 114 that is 
30 using the OS device driver interface 132. 
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Note that while only one device is shown, the 
invention is suitable for use with any number of 
devices in a set- top. 

In the architecture of FIG. 1, the OS-specific 
5 device driver 142 controls or drives the device driver 

core control 154 using the second device driver 
abstract interface 152. In particular, this level 140 
with the . OS-specific device driver 142 converts or 
transforms OS-specific device driver calls (tied 
10 specifically to an OS) into abstract device driver 

calls that are defined by the device driver abstract 
interface 152 . 

The OS itself invokes services within the OS- 
specific device driver 142 through the operating 
15 system's defined driver interface 132. The OS may be 

Microsoft (tm) Windows CE, for example. This OS invokes 
calls having the format "xxx_IOCTL n within a Windows CE 
Device Driver, where "xxx" represents the Windows CE 
names of the device. . . 

20 Regarding driver calls, Windows CE represents an 

example where a proxy would invoke a "DeviceloControl" 
call to passing the Win CE name of the device. 

The device driver proxy 124 represents the device 
driver 154 to the client 112 using the abstract 
25 interface 122, which is functionally the same as the 

device driver abstract interface 152 that is 
implemented by the device driver core control 154. 
These clients can include, e.g., middleware and 
applications. Hence, it appears as if the client is 
30 interfacing directly to the driver core itself. 

Moreover, the proxy 124 converts or transforms 
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interface service requests from the client 112 into 
their associated OS-specific system device. 

Additionally, the abstract interfaces 122 , 152 
handle data that is communicated from the driver to the 
5 client, which can be synchronous or asynchronous. With 

synchronous communication, the driver 154 only provides 
data to the client 110, 114 when asked. The data is 
transferred across the OS driver boundary as described 
in connection with the client to driver communication. 

10 Asynchronous communication occurs when a driver 

wishes to send a client data (e.g., a message) without 
the client asking for it. Note that the driver can 
only inform the client that it has data, and the client 
must then synchronously retrieve the data. This is 

15 summarized by the following steps: 

1. Driver wishes to transfer data to the client. 

2. The driver signals the client asynchronously 
through an event . 

3. Client issues a synchronous operation to 
20 retrieve or read the data. 

To summarize, the device driver proxy 124 converts 
abstract interface requests from a client 110 into OS- 
specific device driver system calls. The OS, in turn, 
invokes OS-specific driver entry points. The OS- 

25 specific driver 142 converts the request back into a 

driver abstract interface request, which is the same 
interface call that the client originally performed. 
This request is executed in the device driver core 154. 
Finally, external clients can chose' two interface 

10 paths when accessing drivers. First, the abstract 

interface 122, 152 can be used in the manner the 
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internal clients (e.g., clients developed by the set- 
top manufacturer) use it, such as the client 112 is 
doing in FIG. 1. Second, the OS driver interface can 

be directly used, as the client 114 is doing in FIG 1. 
5 An external client is external to the set- top 

manufacturer. External clients include any entity that 

needs to use the manufacturer's driver including, e.g., 

a middleware developer such as Liberate 

Technologies (tm) , San Carlos, California, USA, or an OS 
10 developer such as Microsoft . 

FIG. 2 illustrates a device driver abstract 
interface model for use with an operating system that 
does not have a dedicated device driver interface in 
accordance with the present invention. 
15 The hierarchical model 2 00 includes levels 210, 

250 and 260. The bottom level 260 includes the 
hardware device 262. The next abstract level 250 
includes a device driver abstract interface 252, a 
device driver core control 254, and an OS-specific 
20 driver support 256. 

The next level 210 includes the client 212 that is 
using the abstract interface 252 . 

In particular, FIG. 2 refers to a set-top system 
containing an OS without a device driver interface. An 
25 example of such an OS is VRTX from Mentor Graphics 

Corporation, Wilsonville, Oregon, USA. 

This layered architecture compresses (e.g., fewer 
layers are required) when the OS does not require the 
use of a dedicated OS-specific interface. Here, the 
30 client 212, again, views the device driver 254 using 

the device driver abstract interface 252. But, the 
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client directly connects to the driver core 254. Only 
the abstract interface 252 is available under the OS 
without dedicated driver interfaces. 

Similarly, the device ^driver 254 views the client 
via the interface 252 to allow two-way communication. 

Accordingly, it can be seen that the present 
invention provides an abstract interface model for 
device drivers in a set -top terminal. 

The benefits of the invention are as follows . To 
clients using the abstract interface, the device driver 
always appears the same. The client does not need to 
be redeveloped for each operating system. Also, the 
client cannot tell or see the difference between the 
two very different OS implementations (see FIGs 1 and 
15 2 )- Th e driver appears the same. A key point is that 

the device drivers support an abstract interface 
allowing clients to be developed once, and utilized 
across operating systems .* 

Additionally, to the driver core control, the 
20 client always appears the same. The core logic cannot 

tell the difference between clients using the abstract 
interface/proxies, clients using the OS driver 
interface without the abstract interface/proxies, or 
clients directly accessing the core, as in FIG. 2. 
25 The driver core control sub- system is implemented 

in a OS -independent manner. Typically, this sub- system 
requires a great amount of effort to develop (e.g., up 
to 90% of all driver development man-hours) . However, 
since the driver core control sub- system of the. 
invention only needs to be developed once, and can then 
be utilized across different OS platforms, the abstract 
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device driver model can greatly improve the time to 
market for new set-top products. 

Moreover, the invention allows the use of 
alternative device driver user interfaces, 
5 Although the invention has been described in 

connection with various specific embodiments, those 
skilled in the art will appreciate that numerous 
adaptations and modifications may be made thereto 
without departing from the spirit and scope of the 
10 invention as set forth in the claims. 

For example, while the invention was discussed in 
connection with a cable or satellite television 
broadband communication networks, it will be 
appreciated that other networks such as local area 
15 networks (LANs), metropolitan area networks (MANs) , 

wide area networks (WANs) , internets, intranets, and 
the Internet,, or combinations thereof, may be used. 

Moreover, the invention may be implemented using 
any known hardware, firmware and/or software 
20 techniques. 
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What is claimed is: 

1. A method for allowing communication between a 
client and a device driver in a terminal, said terminal 
having an associated specific operating system under 
which the device driver operates, comprising the step 
of: 

providing a first abstract interface for 
converting a service request from the client that has a 
format that is operating system- independent into a call 
to the device driver that has a format that is 
compatible with the specific operating system. 

2. The method of claim 1, comprising the further 
step of : 

using the first abstract interface for converting 
a message from the device driver that is in the format 
of the specific operating system to a corresponding 
message in the operating system- independent format for 
use by the client . 

3. The method of claim 1, wherein: 

the terminal is a subscriber television terminal 
in a network . 

4. The method of claim 1, wherein: 

the terminal is in a broadband communication 
network. 
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5. The method of claim 1, wherein: 

the first abstract interface is adapted to provide 
the call to the device driver in any one of a plurality 
of different formats that are compatible with a 
corresponding plurality of different operating systems. 

6. The method of claim 1, comprising the further 
step of : 

providing the call to the device driver via a 
device driver interface that operates according to the 
specific operating system. 

7. The method of claim 6, wherein: 

the device driver interface is adapted to receive 
a second call directly from another client that has a 
format that is compatible with the specific operating 
system; and 

the device driver interface provides the second 
call to the device driver via a second abstract 
interface. 

8. The method of claim 6, wherein: 

the first abstract interface is adapted to provide 
the call to the device driver via the device driver 
interface in any one of a plurality of different 
formats that are compatible with a corresponding 
plurality of different operating systems. 
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9. The method of claim 6, comprising the further 
step of: 

providing a second abstract interface for 
converting a message from the device driver that is in 
the compatible format to a corresponding message in the 
operating system- independent format for use by the 
client. 

10. The method of claim 9, comprising the further 
step of : 

providing the message in the operating system- 
independent format for use by the client via the first 
abstract interface. 

11. The method of claim 9, wherein: 

the second abstract interface is adapted to 
convert the message to the client from any one of a 
plurality of different formats that are compatible with 
a corresponding plurality of different operating 
systems to the client's operating system- independent 
format . 

12 . An apparatus for allowing communication 
between a client and a device driver in a terminal, 
said terminal having an associated specific operating 
system under which the device driver operates, 
comprising: 

means for providing a first abstract interface for 
converting a service request from the client that has a 
format that is operating system- independent into a call 
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to the device driver that has a format that is 
compatible with the specific operating system. 

13. A method for allowing communication between a 
client and a device driver in a terminal, said terminal 
having an associated specific operating system under 
which the device driver operates, comprising the step 
of: 

providing a first abstract interface for 
converting a message from the device driver that is in 
the format of the specific operating system to a 
corresponding message in an operating system- 
independent format for use by the client . 

14. The method of claim 13, wherein: 

the first abstract interface is adapted to convert 
the message from any one of a plurality of different 
formats that are- compatible with a corresponding 
plurality of different operating systems into the 
operating system- independent format for use by the 
client. 

15 . An apparatus for allowing communication 
between a client and a device driver in a terminal, 
said terminal having an associated specific operating 
system under which the device driver operates, 
comprising: 

means for providing a first abstract interface for 
converting a message from the device driver that is in 
the format of the specific operating system to a 
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corresponding message in an operating system- 
independent format for use by the client. 
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